资讯频道 → 编程语言
阅读更多

0顶
0踩

编程语言

转载新闻 关于内存泄漏，还有哪些是你不知道的？

2017-04-25 09:52 by 副主编 jihong10102006 评论(0) 有7569人浏览
ios
前言
好久没写东西了，因为最近懒了些，且找不到什么好的题材，所以准备对内存泄漏的问题做一篇整理。内存泄漏问题一直是项目开发中的一大问题，本文力求帮助从事过一段时间工作的iOS开发者快速寻找App中的内存泄漏问题。部分内容比较基础，大神可无视勿喷。

一、从AFNet说起
对于iOS开发者，网络请求类AFNetWorking是再熟悉不过了，对于AFNetWorking的使用我们通常会对通用参数、网址环境切换、网络状态监测、请求错误信息等进行封装。在封装网络请求类时需注意的是需要将请求队列管理者AFHTTPSessionManager声明为单例创建形式。对于该问题，AFNetWorking的作者在gitHub上也指出建议使用者在相同配置下保证AFHTTPSessionManager只有一个，进行全局管理，因此我们可以通过单例形式进行解决。下方展示部分核心代码： 
+ (AFHTTPSessionManager*)defaultNetManager {
    static AFHTTPSessionManager *manager;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        manager = [[AFHTTPSessionManager alloc]init];
        manager.responseSerializer = [AFHTTPResponseSerializer serializer];
    });
    return manager;
}

+ (void)GET:(NSString*)url parameters:(NSDictionary*)parameter returnData:(void (^)(NSData * resultData,NSError * error))returnBlock{
    //请求队列管理者 单例创建形式 防止内存泄漏
    AFHTTPSessionManager * manager = [HttpRequest defaultNetManager];
    [manager GET:url parameters:parameter progress:^(NSProgress * _Nonnull downloadProgress) {

    } success:^(NSURLSessionDataTask * _Nonnull task, id  _Nullable responseObject) {
        returnBlock(responseObject,nil);
    } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
        returnBlock(nil,error);
    }];
}

二、Block循环引用
Block循环引用的问题已是老经常谈了，至今已有多篇文章详细解释其原理及造成循环引用的原因等，不泛画图或实例列举，这里不一一赘述。总结一句话防止Block循环引用就是要防止对象之间引用的闭环出现。举个开发中的实际例子，就拿很多人在用的MJRefresh说起 
self.tableView.mj_header = [MJRefreshNormalHeader headerWithRefreshingBlock:^{
        self.page = 1;
        [self.dataArr removeAllObjects];
        [self loadData];
}];

若在MJRefresh的执行Block中调用当前self或其所属属性，一定要注意循环引用问题。我们简单分析下MJRefresh为什么会造成循环引用问题：
点击进入headerWithRefreshingBlock对应方法即可
#pragma mark - 构造方法 
+ (instancetype)headerWithRefreshingBlock:(MJRefreshComponentRefreshingBlock)refreshingBlock
{
    MJRefreshHeader *cmp = [[self alloc] init];
    cmp.refreshingBlock = refreshingBlock;
    return cmp;
}

这里仅有三行代码，无非就是创建了下拉刷新部分View然后返回，这里比较重要的是cmp.refreshingBlock = refreshingBlock;这一句，这里的refreshingBlock是属于MJRefreshHeader的强引用属性，最后header会成为我们自己tableView的强引用属性mj_header，也就是说self.tableView强引用header, header强引用refreshingBlock，如果refreshingBlock里面强引用self，就成了循环引用，所以必须使用weakSelf，破掉这个循环。画图表示为：

循环引用示意图

闭环为：
self--->self.tableView--->self.tableView.mj_header--->self.tableView.mj_header.refreshingBlock--->self

解决方案大家应该也不陌生 
__weak typeof(self) weakself = self; 
self.tableView.mj_header = [MJRefreshNormalHeader headerWithRefreshingBlock:^{
        __strong typeof(self) strongself = weakself;
        strongself.page = 1;
        [strongself.dataArr removeAllObjects];
        [strongself loadData];
}];

【⚠️strongself是为了防止内存提前释放，有兴趣的童鞋可深入了解，这里不做过多解释了。当然也可借助libextobjc库进行解决，书写为@weakify和@strongify会更方便些。】
相应的对于自定义View中的一些Block传值问题同样需要注意，与上述类似。

三、delegate循环引用问题
delegate循环引用问题比较基础，只需注意将代理属性修饰为weak即可 
@property (nonatomic, weak) id<CustomDelegate> delegate;

下图比较形象的说明了使用weak修饰就是为了防止ViewController和UITableView相互强引用内存无法释放的问题：

delegate循环引用

四、NSTimer循环引用
对于定时器NSTimer，使用不正确也会造成内存泄漏问题。这里简单举个例子，我们声明了一个类TestNSTimer，在其init方法中创建定时器执行操作。 
#import "TestNSTimer.h"

@interface TestNSTimer ()
@property (nonatomic, strong) NSTimer *timer;
@end
@implementation TestNSTimer

- (instancetype)init {
    if (self = [super init]) {
        _timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(timeRefresh:) userInfo:nil repeats:YES];
    }
    return self;
}

- (void)timeRefresh:(NSTimer*)timer {
    NSLog(@"TimeRefresh...");
}

- (void)cleanTimer {
    [_timer invalidate];
    _timer = nil;
}

- (void)dealloc {
    [super dealloc];
    NSLog(@"销毁");
    [self cleanTimer];
}

@end

在外部调用时，将其创建后5秒销毁。 
    TestNSTimer *timer = [[TestNSTimer alloc]init];
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        [timer release];
    });

最后的执行结果为

NSTimer打印结果

可见TestNSTimer对象并没有正常释放，定时器仍然在无限的执行下去。

我们都知道定时器使用完毕时需要将其停止并滞空，但cleanTimer方法到底何时调用呢？在当前类的dealloc方法中吗？并不是，若将cleanTimer方法调用在dealloc方法中会产生如下问题，当前类销毁执行dealloc的前提是定时器需要停止并滞空，而定时器停止并滞空的时机在当前类调用dealloc方法时，这样就造成了互相等待的场景，从而内存一直无法释放。因此需要注意cleanTimer的调用时机从而避免内存无法释放，如上的解决方案为将cleanTimer方法外漏，在外部调用即可。 
TestNSTimer *timer = [[TestNSTimer alloc]init];
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        [timer cleanTimer];
        [timer release];
    });


打印结果

五、非OC对象内存处理
对于iOS开发，ARC模式已发扬光大多年，可能很多人早已忘记当年retain、release的年代，但ARC的出现并不是说我们完全可以忽视内存泄漏的问题。对于一些非OC对象，使用完毕后其内存仍需要我们手动释放。
举个例子，比如常用的滤镜操作调节图片亮度 
CIImage *beginImage = [[CIImage alloc]initWithImage:[UIImage imageNamed:@"yourname.jpg"]];
CIFilter *filter = [CIFilter filterWithName:@"CIColorControls"];
[filter setValue:beginImage forKey:kCIInputImageKey];
[filter setValue:[NSNumber numberWithFloat:.5] forKey:@"inputBrightness"];//亮度-1~1
CIImage *outputImage = [filter outputImage];
//GPU优化
EAGLContext * eaglContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES3];
eaglContext.multiThreaded = YES;
CIContext *context = [CIContext contextWithEAGLContext:eaglContext];
[EAGLContext setCurrentContext:eaglContext];

CGImageRef ref = [context createCGImage:outputImage fromRect:outputImage.extent];
UIImage *endImg = [UIImage imageWithCGImage:ref];
_imageView.image = endImg;
CGImageRelease(ref);//非OC对象需要手动内存释放


在如上代码中的CGImageRef类型变量非OC对象，其需要手动执行释放操作CGImageRelease(ref)，否则会造成大量的内存泄漏导致程序崩溃。其他的对于CoreFoundation框架下的某些对象或变量需要手动释放、C语言代码中的malloc等需要对应free等都需要注意。

五、地图类处理
若项目中使用地图相关类，一定要检测内存情况，因为地图是比较耗费App内存的，因此在根据文档实现某地图相关功能的同时，我们需要注意内存的正确释放，大体需要注意的有需在使用完毕时将地图、代理等滞空为nil，注意地图中标注（大头针）的复用，并且在使用完毕时清空标注数组等。 
- (void)clearMapView{
    self.mapView = nil;
    self.mapView.delegate =nil;
    self.mapView.showsUserLocation = NO;
    [self.mapView removeAnnotations:self.annotations];
    [self.mapView removeOverlays:self.overlays];
    [self.mapView setCompassImage:nil];
}

六、大次数循环内存暴涨问题
记得有道比较经典的面试题，查看如下代码有何问题： 
for (int i = 0; i < 100000; i++) {
        NSString *string = @"Abc";
        string = [string lowercaseString];
        string = [string stringByAppendingString:@"xyz"];
        NSLog(@"%@", string);
}

该循环内产生大量的临时对象，直至循环结束才释放，可能导致内存泄漏，解决方法为在循环中创建自己的autoReleasePool，及时释放占用内存大的临时变量，减少内存占用峰值。 
for (int i = 0; i < 100000; i++) {
        @autoreleasepool {
            NSString *string = @"Abc";
            string = [string lowercaseString];
            string = [string stringByAppendingString:@"xyz"];
            NSLog(@"%@", string);
        }
    }

若对autoReleasePool陌生，可查阅相关资料，毕竟不是一两句即可说明的。

附、如何检测App的内存泄漏问题
1、借助Xcode自带的Instruments工具（⚠️选取真机测试）

Instruments


2、简单暴力的重写dealloc方法，加入断点或打印判断某类是否正常释放。

dealloc


3、通过Facebook出品的FBMemoryProfiler工具类进行检测，感兴趣的童鞋可进行了解。

暂时写到这里，未完待续
  • 大小: 145 KB
  • 大小: 34.5 KB
  • 大小: 10.1 KB
  • 大小: 8.5 KB
  • 大小: 87 KB
  • 大小: 7.2 KB
来自: jianshu
0
顶
0
踩
评论 共 0 条 请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • Spring中依赖注入与容器

    Spring 框架（核心）IoC 容器 IoC：控制反转  DI：依赖注入  什么是依赖?一个组件（对象）的运行需要用到另一个组件（对象），称这种关系为依赖关系  举例：鱼依赖水，生命依赖空气、阳光、水、食物 组件依赖...

  • 浅谈Spring IoC容器的依赖注入原理

    主要介绍了浅谈Spring IoC容器的依赖注入原理，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧

  • Spring 依赖注入详解

    然后，容器在创建 bean 时注入这些依赖项。这个过程基本上是与对象直接通过构造类或等机制来控制其依赖项的实例化或位置是相反的，因此得名控制反转。// 对象不直接创建自己，而是通过 Spring 容器创建，那么 Spring...

  • “IOC容器与DI依赖注入示例”文章提及

    “IOC容器与DI依赖注入示例”文章提及

  • Spring依赖注入检查.

    Spring依赖注入检查，适合初学者进一步了解Spring框架。

  • Spring Boot中的依赖注入和自动注入

    SpringBoot中的依赖注入和自动注入 依赖注入 DI 自动注入 @Autowired

  • Spring DI简介及依赖注入方式和依赖注入类型

    Spring DI简介及依赖注入方式和依赖注入类型

  • spring容器中如何使用Mockito优雅的注入依赖的依赖

    Mockito Spy Mock InjectMocks 正确注入依赖的依赖

  • 如何把new对象手动注入Spring容器并实现依赖注入

    // 将new出的对象放入Spring容器中 defaultListableBeanFactory.registerSingleton("userDao",userDao); // 自动注入依赖 beanFactory.autowireBean(userDao); // 判断new的对象和从容器中拿出的对象是否一致 ...

  • spring依赖注入

    在maven项目中的pom.xml文件中配置spring依赖： &lt;dependency&gt; &lt;groupId&gt;org.springframework&lt;/groupId&gt; &lt;artifactId&gt;spring-context&lt;/artifactId&gt; &lt;version&gt;5.2.6....

  • Spring 的依赖注入

    依赖注入： Dependency Injection，它是 spring 框架核心 IOC 的具体实现，具体点就是依赖关系的维护称之为依赖注入 我们的程序在编写时， 通过控制反转， 把对象的创建交给了 spring，但是代码中不可能出现没有依赖...

  • spring依赖注入三种方式

    spring依赖注入

  • Spring依赖注入

    DI (Dependency Injection)：依赖注入是指在 Spring IOC 容器创建对象的过程中，将所依赖的对象通过配置进行注入。我们可以通过依赖注入的方式来降低对象间的耦合度。 在软件工程中，对象之间的耦合度就是对象之间...

  • Spring依赖注入的三种方式

    还是与属性注入的解释是一样的,原因就是JDK是我们最底层的框架,Spring作为上层,要基于JDK/Java的,所以要满足Java的规范,java规定,被final修饰的属性1.在定义的时候进行赋值2.在构造方法内部进行赋值。原因还是一样的...

  • spring IOC容器依赖注入XML配置

    spring IOC容器依赖注入XML配置详解 运行环境：eclipse 构建工具：maven 不提供maven构建，maven用来解决jar包的依赖

  • spring四种依赖注入方式

    spring提出了依赖注入的思想，即依赖不由程序员控制，而是通过spring容器帮我们new指定实例并且将实例注入到需要该对象的类中。依赖注入的另一种说法是“控制反转”，通俗的理解是：平常我们new一个实例，这个实例的...

  • Spring boot基础 - 依赖注入

    spring boot基础

  • 基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip

    【优质项目推荐】 1、项目代码均经过严格本地测试，运行OK，确保功能稳定后才上传平台。可放心下载并立即投入使用，若遇到任何使用问题，随时欢迎私信反馈与沟通，博主会第一时间回复。 2、项目适用于计算机相关专业（如计科、信息安全、数据科学、人工智能、通信、物联网、自动化、电子信息等）的在校学生、专业教师，或企业员工，小白入门等都适用。 3、该项目不仅具有很高的学习借鉴价值，对于初学者来说，也是入门进阶的绝佳选择；当然也可以直接用于 毕设、课设、期末大作业或项目初期立项演示等。 3、开放创新：如果您有一定基础，且热爱探索钻研，可以在此代码基础上二次开发，进行修改、扩展，创造出属于自己的独特应用。 欢迎下载使用优质资源！欢迎借鉴使用，并欢迎学习交流，共同探索编程的无穷魅力！ 基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip 基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip 基于业务逻辑生成特征变量python实现源码+数据集+超详细注释.zip

  • 六一儿童节快乐！（六一儿童节庆祝代码）Vue开发

    六一儿童节快乐！（六一儿童节庆祝代码）Vue开发 like Project setup npm install Compiles and hot-reloads for development npm run serve Compiles and minifies for production npm run build Lints and fixes files npm run lint Customize configuration

  • uniapp聊天工具源码.zip

    提供的源码资源涵盖了安卓应用、小程序、Python应用和Java应用等多个领域，每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写，确保了在对应环境下能够无缝运行。同时，源码中配备了详细的注释和文档，帮助用户快速理解代码结构和实现逻辑。 适用人群： 这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生，还是对其他领域编程感兴趣的学生，这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码，你可以掌握各平台开发的基础知识，提升编程能力和项目实战经验。 使用场景及目标： 在学习阶段，你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码，你将深入了解各平台开发的技术细节和最佳实践，逐步培养起自己的项目开发和问题解决能力。此外，在求职或创业过程中，具备跨平台开发能力的大学生将更具竞争力。 其他说明： 为了确保源码资源的可运行性和易用性，特别注意了以下几点：首先，每份源码都提供了详细的运行环境和依赖说明，确保用户能够轻松搭建起开发环境；其次，源码中的注释和文档都非常完善，方便用户快速上手和理解代码；最后，我会定期更新这些源码资源，以适应各平台技术的最新发展和市场需求。

Global site tag (gtag.js) - Google Analytics